The signalling is an important component in all telecommunication networks, and a conventional signalling protocol may use a hard-state signalling approach, a soft-state signalling approach, or a combination of soft-state and hard-state signalling.
In soft-state signalling, a session will be ended by a time-out, unless the state is refreshed by a refresh requesting message received before the expiry of a negotiated refresh interval. Refresh requesting messages are normally transmitted periodically after an initial installation of a state, indicating that the dialogue should be kept alive. Thus, soft state signalling does not require any explicit removal of a state, nor any reliable signalling, since the server state is automatically removed in case of lost signalling due to e.g. network errors.
In hard-state signalling, on the contrary, an installed state will remain installed, unless explicitly removed by a message transmitted by the client terminal. Since installation and removal of a state is only performed once, a reliable signalling is required.
The SIP (Session Initiating Protocol) conventionally uses a soft state signalling, in which two communicating terminals, i.e. SIP User Agents, maintain a session by continuously refreshing the state of the session. A SIP User Agent acting as a service requesting device, e.g. a client terminal, is called a UAC (User Agent Client), and a SIP User Agent responding to a request for a service, e.g. a server terminal, is called a UAS (User Agent Server). A client terminal may be distributed between different implementation devices, each device hosting a UAC.
In a session initiating requesting message from a client terminal for initiating a SIP dialogue between the client terminal and a server terminal, as well as in the session refresh requesting messages from the client terminal for refreshing the SIP dialogue, the client terminal (UAC, User Agent Client) proposes a suitable, large, value of the refresh interval, e.g. 1800 seconds, in a Session-Expires attribute attached to a header in the refresh requesting message. The server terminal (UAS, User Agent Server) has an option to negotiate the proposed value of the refresh interval by returning a reduced value in a response. However, before the expiration of the refresh interval indicated by the Session-Expires, a subsequent refresh requesting message must be received by the server terminal, otherwise the dialogue will be terminated.
Thus, a soft state SIP-dialogue is maintained by a periodic refresh within a negotiated refresh interval set in the Session-Expires of a session initiation requesting message and the consecutive session refresh requesting messages. However, if a client terminal is maintaining dialogues with multiple server terminals simultaneously over the same radio link, this refresh traffic will be power consuming, and eventually drain the battery. The marginal cost, in terms of energy, to send an IP packet over the radio interface depends on the pre-transmission state of the terminal and its radio equipment. When a client terminal and the radio equipment is in a low-power mode, or powered off, the marginal cost to send an IP-packet will be high, due to the transitioning of the equipment into an operational state, but the cost to send the consecutive IP-packets will be low.
The energy consumption in a client terminal caused by the refresh requests during a typical SIP dialogue with a server terminal is illustrated in the Energy vs Time-diagram in FIG. 1, in which refresh requesting messages, indicated by 1a, 1b and 1c are transmitted on the time instances t0, t1, and t2, respectively. The illustrated refresh intervals t1-t0 and t2-t1 are approximately equal, which results in a repeating pattern of session refresh requesting messages.
FIG. 2 illustrates the energy consumption in a client terminal maintaining multiple SIP-dialogues, SIP-Dialogue 1 and SIP-Dialogue 2, with two server terminals simultaneously. Typically, a client terminal will propose the same, large, refresh interval in the refresh requesting messages to the different server terminal. As illustrated in the figure, a client terminal is likely to be in a high-energy consumption state when maintaining multiple SIP-dialogues, since each refresh request may require a transition from power-off or a low power mode into an operational state.
Energy is also consumed when the terminal is down-powered, during the time interval when the terminal is unable to send, but before power-off, as well as during the high-power interval between the last transmission and the initiation of the power-off sequence.
Since a multi-dialogue scenario is common e.g. in SIP-based IMS (IP Multimedia Subsystem) services, such as registration, presence, and voice services, an IMS client terminal may have a high energy consumption, which will drain the battery quickly.
Related art within this technical field is described e.g. in NOKIA: “Power Save Topics for mobile Battery Powered Wireless Devices”, 21 Aug. 2001, which mentions, on page 4, that application require keep-alives from the terminal, and on page 9 that the timers could be configured to be synchronized, as well as in Kant: “Towards a Virtualized Data Center Transport Protocol”, which mentions a coordination among multiple device, e.g. by a delay of a transmission of a burst.